Grouping of user identities in an IP multimedia subsystem

ABSTRACT

The present invention is aimed to provide a more flexible data structure where any IMPU, even those of the SIP URI type, may be shared by more than one IRS in order to simplify the registration of an IMPU for users of a Fixed-Mobile Convergent network. To this end, there is provided a flexible data structure wherein a number n of IMPUs of a user may be distributed in a number m of Implicit Registration Sets, wherein a given IMPU may be shared by more than one IRS, each IRS is associated with an access condition, and the explicit registration of said given IMPU under a given access condition triggers the implicit registration of those IMPUs in the IRS associated with said access condition, while the registration status of IMPUs in any other IRS remain unchanged.

TECHNICAL FIELD

The present invention generally relates to implicit registration ofpublic user identities in an IP Multimedia Subsystem and, in particular,where applied in a fixed-mobile convergent scenario.

BACKGROUND

In accordance with 3GPP technical specifications, namely TS 23.228,every user subscription of the IP Multimedia Subsystem (hereinafter IMS)is assigned one or more IMS Private User Identities by the Home networkoperator. Each IMS Private User Identity (hereinafter IMPI) is used forregistration of the user in the IMS, and may be associated with one ormore IMS Public User Identities. Each IMS Public User Identity(hereinafter IMPU) is used by the user for communications with otherusers and may be associated with a unique IMS Service Profile(hereinafter SP) and with one or more IMPIs. In this respect, any SP maybe associated with more than one IMPU, whereas each IMPU can only beassociated with one SP. An SP being, in short, a collection of serviceand user related data.

At present, a plurality of IMPUs may be included in an ImplicitRegistration Set (hereinafter IRS) wherein all the IMPUs share a sameregistration status and are associated with a same set of IMPIs. Thus,where an IMPI/IMPU pair is explicitly registered or deregistered, andthe IMPU belongs to an IRS, all the IMPUs in the IRS are simultaneouslyconsidered implicitly registered or de-registered by the network withoutrequiring explicit registration or de-registration for all of them. Forthe purpose of the present invention, where several IMPUs share a singleSP and are included in a same IRS, said several IMPUs are considered tobe aliases.

In accordance with the above understanding of an IRS, wherein all theIMPUs share a same registration status and are associated with a sameset of IMPIs, one infers that an IMPU can only belong to one IRS.Otherwise, where the IMPU is included in two IRSs, all the IMPUs in thetwo IRSs would have the same registration state, so that it wouldeffectively be just one IRS. Or putting it in another way, two differentIRSs imply two sets of IMPUs having a different registration state; sothat any IMPU in the two IRSs would have two different registrationstates at the same time, which is not possible.

The exemplary data structure illustrated in FIG. 1 shows a subscriptionwith two IMPIs, namely IMPI-1 and IMPI-2, nine IMPUs, namely IMPU-1 toIMPU-9, and three IRSs, namely IRS-1 to IRS-3, in which some of theIMPUs are distributed and wherein all the IMPUs in each IRS areassociated with the same at least one IMPI. In this exemplary datastructure, IMPU-3 is associated with IMPI-1 and IMPU-2, whereas IMPU-6is only associated with IMPI-2. In this situation, IMPU-3 may beregistered using any of IMPI-1 or IMPU-2, whereas IMPU-6 can only beregistered using IMPU-2.

Also in this exemplary data structure, IRS-1 consists of IMPU-1 andIMPU-2 both only associated with IMPI-1, so that the explicitregistration of either IMPU-1 or IMPU-2 can only be carried out withIMPI-1, and triggers the implicit registration of either IMPU-2 orIMPU-1 respectively. The IRS-2, however, consists of IMPU-4 and IMPU-5both individually associated with both IMPI-1 and IMPI-2, so that theexplicit registration of either IMPU-1 or IMPU-2 can be carried outeither with IMPI-1 or with IMPI-2, and triggers the implicitregistration of either IMPU-2 or IMPU-1 respectively and for the sameeither IMPI-1 or IMPI-2. The IRS-3, on the other hand, consists ofIMPU-7, IMPU-8 and IMPU-9 all only associated with IMPI-2, so that theexplicit registration of either IMPU-7, IMPU-8 or IMPU-9 can only becarried out with IMPI-2, and triggers the implicit registration of allthe three IMPUs. In particular, since IMPU-7 and IMPU-8 are bothassociated with a unique SP, namely SP-E in this FIG. 1, and given thatboth IMPU-7 and IMPU-8 are included in the same IRS, namely IRS-3, bothIMPU-7 and IMPU-8 are said to be alias to each other, and they can beused indistinctly since the treatment made by the network is the samefor both.

Once the above exemplary data structure with the conventionalrelationships between IMPUs, IMPIs, IRSs and SPs has been presented, arationale for introducing the IRS may be worthwhile. On the one hand,IMS makes use of the so-called Session Initiation Protocol (hereinafterSIP), wherein user identifiers are preferably in the form of a so-calledSIP URI, such as ‘sip: user@ims.com’. On the other hand, users of awireline telephony network are generally identified by a subscribernumber in the form of a so-called TEL URI, such as ‘tel: +987656789’. Inaccordance with the IETF SIP specification, a TEL URI cannot beexplicitly registered. However, users of the IMS should also bereachable with a TEL URI, especially in the context of emergency calls.To overcome this, the concept of IRS was introduced to allow a set ofIMPUs in the form of TEL URI and SIP URI being implicitly registeredupon the explicit registration of an IMPU of said IRS, said IMPU in theform of a SIP URI. Even though SIP URI and TEL URI are formallyexpressed with a respective prefix as indicated above ‘sip:user@ims.com’ and ‘tel: +987656789’ respectively, in the following, andfor the sake of simplicity, they are simply referred to as‘user@ims.com’ and ‘+987656789’ respectively.

When considering a fixed-mobile convergent network (hereinafter FMC) foraccessing the IMS, a user may have IMPUs of a SIP URI type, such asbob@wireline and bob@wireless, and IMPUs of a TEL URI type, such as+1234567890 identifying a mobile terminal and +9876543210 identifying awireline terminal. Such FMC user may have: a mobile handset reachable byan MSISDN, and having a so-called SIP User Agent (hereinafter SIP UA); awireline telephone reachable with an E.164 subscriber number; a desktopPersonal Computer (hereinafter PC) with a software-based SIP UA; andlikely an IPTV set-top box (hereinafter STB) with an embedded SIP UA.Moreover, different TEL URIs are necessary for wireline and mobileterminals since calls from another operator network typically have alower cost where calling to a wireline terminal than the cost of thatsame call to a mobile terminal and thus the calling user should be giventhe choice of dialling a wireline terminal or a mobile terminal.

Thus, this FMC user may be given under the conventional data structureillustrated in FIG. 1 a first IRS with a first IMPU +9876543210 of theTEL URI type identifying the wireline terminal and a second IMPUbob@wireline of the SIP URI type identifying, for example, the desktopPersonal Computer (hereinafter PC) and likely the IPTV STB; and a secondIRS with a first IMPU +1234567890 of the TEL URI type, namely an MSISDN,identifying the mobile terminal and a second IMPU bob@wireless of theSIP URI type identifying the SIP UA in the mobile terminal. Inoperation, where the SIP UA in the mobile terminal registers the IMPUbob@wireless, the network automatically registers the IMPU +1234567890of the TEL URI type representing the mobile terminal MSISDN number. Alsoin operation, where the SIP UA in either the desktop PC or the IPTV STBregisters the IMPU bob@wireline, the network automatically registers theIMPU +9876543210 of the TEL URI type representing the wireline terminalISDN number.

This FMC user may also have an IMPU of the SIP URI type identifying theuser in the IMS, such as bob@ims.com, and even an alias IMPU of the SIPURI type also identifying the user in the IMS, such as bob@bobdomain. Atpresent, these two IMPUs identifying the user in the IMS may preferablybe included in a third IRS under the above data structure, and cannot bedefined in both IRSs discussed above for the wireline and wirelessenvironments since they might have a different registration statusdepending on what implicit registration has taken place in operation.Therefore, the user should firstly register the wireline or wirelessIRS, and then make a successive registration of the IMPU bob@ims.com.

On the other hand, within the context of emergency calls through theIMS, regulatory requirements impose that each terminal performing a callto an emergency response centre (hereinafter ERC) must be reachable viaa plain E.164 number. At the same time, standardization bodies haveagreed that where a not registered user registers with the objective ofinitiating an emergency call, this user must use a so-called “EmergencyPublic Identity” (hereinafter E-IMPU) which is a SIP URI different fromany other IMPU associated with the user. From this background, one mayinfer that the E.164 number for emergency calls, as mandated byregulatory requirements, cannot be the same as the MSISDN identifyingthe mobile terminal or the ISDN subscriber number identifying thewireline terminal, since that would imply that the MSISDN or ISDNsubscriber number must be part of two different IRS at the same time,what is not possible nowadays. Thus, in order to accomplish theregulatory requirements, an additional TEL URI may be assigned with theE.164 number for each user that can only be used for emergency calls.

This apparent first solution forces the reservation of one additionalidentifier, namely an emergency TEL URI, in addition to the above E-IMPUof the SIP URI type for every subscriber. This identifiers can only beused for emergency calls, but the operator needs to request a muchlarger numbering space from the administration, and the above drawbackof successive implicit registrations for users of a FMC network is evenmaximized. In addition, this solution implies that the ERC would see adifferent subscriber identifier for calling back the user where the useraccesses the ERC from the IMS domain than where the user accesses theERC from a conventional telephony domain, what may cause an additionaldifficulty in identifying the origin of the emergency call.

In attempting to overcome this, a second solution is nowadays underdiscussion in 3GPP standardization bodies, and whereby a TEL URI usablefor emergency calls might be shared by more than one IRS, as in FIG. 2illustrates. This second solution proposes a first IRS with IMPUs onlyusable for emergency calls and at least one second IRS with IMPUsnon-usable for emergency calls, both IRSs sharing the TEL URI usable foremergency calls. In operation, where the user explicitly registers anIMPU of the SIP URI type in the IRS for emergency calls, all the IMPUsin said IRS including the TEL URI are implicitly registered foremergency calls, and this registration does not affect the registrationstate of the TEL URI and other IMPUs in other IRSs. Since the only IMPUshared by more than one IRS in this solution is of TEL URI type, andgiven that a TEL URI cannot be explicitly registered, this solution doesnot solve the above drawback of successive registrations for FMC users.Moreover, in view of this solution, the above FMC user may be given anIRS for emergency calls having as TEL URI either the +1234567890representing the mobile terminal MSISDN number, or the +9876543210representing the wireline terminal ISDN number, whilst the user isregistered in the other environment respectively. In other words, thissolution does not solve the problem of sharing IMPUs of the SIP URI typeidentifying the user in the IMS amongst more than one IRS.

SUMMARY

It is an object of the present invention to obviate at least some of theabove disadvantages and provide for a more flexible grouping of useridentities in the IMS. More specifically, and especially applicable toFMC users, the present invention is aimed to provide a more flexibledata structure where any IMPU, even those of the SIP URI type, may beshared by more than one IRS.

The object above is generally accomplished in accordance with theinvention by providing a Home Subscriber Server (hereinafter HSS)holding such flexible data structure per subscriber of the IMS, a methodof carrying out the implicit registration of an IRS sharing a given IMPUwith another IRS, and a Serving Call Session Control Function(hereinafter S-CSCF) server serving subscribers of the IMS andcooperating with the HSS to determine the IRS to be implicitlyregistered.

Thus, in accordance with a first aspect of the present invention, thereis provided a HSS holding subscriber data of users of the IMS, this HSShaving a data structure per subscriber that includes a plurality ofIMPUs, each IMPU associated with at least one IMPI, wherein a number nof IMPUs is distributed in a number m of IRSs, and wherein all the IMPUsin each IRS share the same registration status. In this HSS, each IRS isassociated with an access condition, a given IMPU is shared by more thanone IRS, and the explicit registration of said given IMPU under a givenaccess condition triggers the implicit registration of those IMPUs inthe IRS associated with said access condition, whilst the registrationstatus of IMPUs in any other IRS associated with a different accesscondition remain unchanged. Moreover, an explicit registration in thisHSS of an IMPU, which belongs only to one IRS, also triggers an implicitregistration of those IMPUs in said IRS for the associated accesscondition.

Generally speaking, and applicable to the HSS as well as to the S-CSCFand the method, the given access condition may be selected from a groupof access conditions that includes: a mobile access only, a fixed accessonly, emergency call, roaming network, and combinations thereof. Morespecifically, an access condition may be built up by performing a logicoperation with a combination of individual conditions such as an ORselection between several fixed access networks plus an AND with anemergency call condition.

In order to preclude partial deregistration of the IMPUs in an IRS, anyimplicit registration of IMPUs in the IRS is recorded in the HSS. Then,a deregistration of an IMPU in an IRS, which implicit registration wasrecorded, triggers the deregistration of those IMPUs in said IRS.

Regarding implementation, this HSS may comprise a storage for storingthe data structure per subscriber; a receiver for receiving the explicitregistration of the given IMPU under the given access condition; and aprocessor for triggering the implicit registration of IMPUs in the IRSassociated with said access condition. This HSS may further comprise asender for submitting those IMPUs in the IRS as a result of the explicitregistration of the given IMPU.

In particular, the storage of this HSS may comprise a memory handler forsubmitting and retrieving data from an external database, or maydirectly include an internal database to this end.

Regarding above advantages, the processor of this HSS may be arrangedfor recording in the storage the implicit registration of IMPUs in anyIRS in order to preclude partial deregistration of IMPUs in said IRS.Moreover, the receiver of this HSS may be arranged for receiving aderegistration of an IMPU in an IRS, which implicit registration wasrecorded in the storage, and the processor may be arranged fortriggering the deregistration of those IMPUs in said IRS. Furthermore,the receiver of this HSS may further be arranged for receiving a givenaccess condition along with a deregistration of an IMPU, and theprocessor may further be arranged for using the given access conditionto determine a deregistration of those IMPUs in an IRS associated withsaid access condition.

In accordance with a second aspect of the present invention, there isprovided a method of carrying out an implicit registration of one IRSamongst a plurality of IRSs in a HSS, wherein each IRS comprises morethan one IMPU and the IMPUs in each IRS share a same registrationstatus. This method comprises a step of distributing a number n of IMPUsin a number m of IRSs; a step of sharing a given IMPU by more than oneIRS; a step of associating each IRS with an access condition; a step ofcarrying out a explicit registration of the given IMPU under a givenaccess condition; and a step of triggering an implicit registration inthe HSS of those IMPUs in an IRS associated with said given accesscondition, whilst the registration status of IMPUs in any other IRSassociated with a different access condition remain unchanged. Moreover,this method may further comprise a step of carrying out a explicitregistration of a second IMPU, which belongs only to one IRS, and aresponsive step of triggering an implicit registration of those IMPUs insaid IRS for the associated access condition.

Aligned with advantageous features provided for in the HSS, this methodmay further comprise a step of recording the implicit registration ofIMPUs in any IRS, in order to preclude partial deregistration of IMPUsin said IRS. Moreover, this method may further comprise a step ofderegistering those IMPUs in an IRS, which implicit registration wasrecorded, upon a deregistration of an IMPU in said IRS. Furthermore,this method may also comprise a step of receiving a given accesscondition along with a deregistration of an IMPU, and a step of usingthe given access condition to determine a deregistration of those IMPUsin an IRS associated with said access condition.

In accordance with a third aspect of the present invention, there isprovided a S-CSCF serving subscribers of the IMS. This S-CSCF includes areceiver for receiving an explicit registration of an IMPU of a givensubscriber, and a sender for submitting the explicit registration ofsaid IMPU towards a HSS holding subscriber data for users of the IMS. Inthis S-CSCF, the sender is arranged for submitting a given accesscondition for which the explicit registration applies. Moreover, thesender may further be arranged for submitting towards the HSS, alongwith a deregistration of an IMPU, a given access condition for which thederegistration applies.

The invention may be practised by one or more computer programs,loadable into an internal memory of a number of computers, each one withinput and output units as well as with a processing unit, the computerprogram comprising executable code adapted to carry out method stepsaccording to any of claims 14 to 20 when running in the computer. Theexecutable code of the one or more computer programs may be recorded ina carrier readable in a computer.

BRIEF DESCRIPTION OF THE DRAWINGS

The features, objects and advantages of the invention will becomeapparent by reading this description in conjunction with theaccompanying drawings, in which:

FIG. 1 represents an exemplary distribution of IMPUs in IRSs inaccordance with conventional subscriber data for IMS, whereby no IMPUcan be shared by more than one IRS.

FIG. 2 represents another exemplary distribution of IMPUs in IRSs, inaccordance with discussions currently held in standardization fora,whereby just an IMPU of a TEL URI type can be shared by more than oneIRS, whilst no IMPU that can be explicitly registered can be shared bymore than one IRS.

FIG. 3 illustrates an exemplary Fixed-Mobile Convergent network, whereina user is given several IMPUs usable in a fixed or wireline environment,several IMPUs usable in a mobile or wireless environment, and severalIMPUs usable for accessing the IMS through the fixed or mobileenvironment.

FIG. 4 illustrates an exemplary data structure whereby any IMPU can beshared by more than one IRS, and each IRS is associated with an accesscondition which matching during the explicit registration of an IMPU inthe IRS triggers an implicit registration of those IMPUs in said IRS.

FIG. 5 illustrates an exemplary embodiment of the data structureapplicable to emergency calls, and wherein a special emergency-IMPU iswanted to be shared by more than one IRS and to be used for explicitregistration.

FIG. 6 illustrates an exemplary embodiment of a method for emergencycalls where the exemplary data structure illustrated in FIG. 5 applies.

FIG. 7 illustrates an exemplary embodiment of a method for implicitregistration of two different IRSs, each one associated with aparticular access condition as illustrated in FIG. 4, upon a userregistering an IMPU shared by both IRSs under respective accessconditions.

FIG. 8 illustrates an exemplary embodiment of a possible sequence ofcalls carried out from another user to reach the user who had registeredthe two different IRSs as illustrated in FIG. 7.

FIG. 9 represents basic structural elements of a HSS supporting the datastructure and triggering the implicit registrations, and a S-CSCFindicating basic information to derive access conditions.

FIG. 10 illustrates an exemplary embodiment of possible sequences ofactions to explicitly make an IMPU unregistered and deregistered as wellas to respectively make corresponding IRSs unregistered and deregisteredunder respective access conditions.

DETAILED DESCRIPTION

The following describes some preferred embodiments for a HSS holding aflexible data structure per subscriber of the IMS, a method of carryingout the implicit registration of an IRS sharing a given IMPU withanother IRS, and a S-CSCF server serving subscribers of the IMS andproviding towards the HSS basic information to derive access conditions,they all cooperating to provide a more flexible data structure where anyIMPU, even those of the SIP URI type, may be shared by more than oneIRS.

FIG. 3 illustrates a scenario where an IMS user may access the IMS 8through a so-called Fixed-Mobile Convergent network, as alreadycommented above when discussing the drawbacks aiming the presentinvention. A Fixed-Mobile Convergent network, namely an FMC network, maybe understood as a network where a user 91 may get connected with otherusers 92 via a fixed or wireline network 61-62, or via a mobile,cellular or wireless network 63. Where the user 91 has a wirelineconnection, the user may connect a desktop PC 9 d, an IPTV STB 9 c, anda conventional telephone 9 b, for example. On the other hand, where sucha user 91 is an FMC user, the user may also have a wireless connectionthrough a mobile terminal 9 a, where the user might even connect alaptop PC (not illustrated in any drawing) to access the IMS 8 through.

In this exemplary scenario illustrated in FIG. 3, the FMC user 91 isgiven a first IMPU 2 a such as Bob@ims.com, namely IMPU-1, to identifythe user in the IMS; a second IMPU 2 b such as Bob@wireless, namelyIMPU-2, to identify, for example, an e-mail account in the laptop PCconnected with the mobile terminal 9 a; a third IMPU 2 c of a TEL URItype such as +1234567890, namely IMPU-3, to identify the mobile terminalMSISDN for fixed and mobile telephony services; a fourth IMPU 2 d suchas Bob@wireline, namely IMPU-4, to identify, for example, any userapplication in the desktop PC 9 d or the IPTV STB 9 c, both connectedwith the wireline network; a fifth IMPU 2 e of a TEL URI type such as+9876543210, namely IMPU-5, to identify the wireline terminal ISDNnumber for fixed and mobile telephony services; and a sixth IMPU 2 fsuch as Bob@bobdomain, namely IMPU-6, to identify a user alias in theIMS, for example, an identity related with a work position or withprivate activities.

Where the present invention addresses the issue of sharing an IMPU of agiven user amongst more than one IRS, for example, sharing IMPU-1 by afirst IRS with IMPUs in the home environment and a second IRS with IMPUsin the mobile environment, an exemplary data structure such as the oneillustrated in FIG. 4 may be provided for the given user.

The data structure illustrated in FIG. 4 includes a first IRS 71, namelyIRS-1, to be implicitly registered where the user accesses the IMS 8through the home environment shown in FIG. 3, that is, through a firstaccess network 61 or through a second access network 62; and a secondIRS 72, namely IRS-2, to be implicitly registered where the useraccesses the IMS 8 through the mobile environment shown in FIG. 3, thatis, through a third access network 63. For the sake of simplicity inrespect of the present invention, all IMPUs in both IRS-1 and IRS-2 areassociated with a couple of IMPIs of the given user 91, namely IMPI-13 aand IMPI-2 3 b.

The first IRS 71, namely IRS-1, representing the home environment maythus include the IMPU-12 a to be shared, namely Bob@ims.com, identifyingthe user in the IMS 8, and those IMPUs of the user 91 in the homeenvironment: the IMPU-4 2 d, namely Bob@wireline, identifying any userapplication in the desktop PC 9 d or the IPTV STB 9 c, and the IMPU-5 2e, namely +9876543210, identifying the wireline terminal 9 b ISDN numberfor fixed and mobile telephony services. In addition, this IRS-1 alsoincludes any other alias IMPU of IMPU-1 such as IMPU-6 2 f, namelyBob@bobdomain. This IRS-1 71 also includes, in accordance with theinvention, an access condition 41 to be matched in order to carry outthe implicit registration of IMPUs in the IRS-1. In this case, theaccess condition 41 is built up as a result of accessing the IMS 8through either the first access network 61, or the second access network62 or both.

Generally speaking, an access condition included in any IRS may beunderstood as a result of a logic operation (which makes use oftraditional logic operators such as AND, OR, NOT, etc) with individualconditions selected from a group of conditions including: a mobileaccess only, a fixed access only, emergency call, roaming network,individual access networks, and combinations thereof.

Moreover, the IRS-1 also includes a registration status 51 to indicatethe registration status applicable for all the IMPUs in said IRS-1. Inparticular, as shown in FIG. 4, both IMPU-12 a and IMPU-6 2 f share aunique SP, namely SP-A 6 a; whereas both IMPU-4 2 d and IMPU-5 2 e sharea unique SP, namely SP-B 6 b. As already commented above, IMPU-1 andIMPU-6 sharing a unique SP and being included in the same IRS are saidto be alias IMPUs, as IMPU-4 and IMPU-5 respectively do.

The second IRS 72, namely IRS-2, representing the mobile environment mayalso include the IMPU-12 a to be shared, namely Bob@ims.com, identifyingthe user in the IMS 8, and those IMPUs of the user 91 in the mobileenvironment: the IMPU-2 2 b, namely Bob@wireless, identifying an e-mailaccount for the user in the laptop PC connected with the mobile terminal9 a, and the IMPU-3 2 c, namely +1234567890, identifying the mobileterminal 9 a MSISDN for fixed and mobile telephony services. Inaddition, this IRS-2 also includes IMPU-6 2 f, namely Bob@bobdomain, asalias IMPU of IMPU-1. This IRS-2 72 also includes, in accordance withthe invention, an access condition 42 to be matched in order to carryout the implicit registration of IMPUs in the IRS-2. In this case, theaccess condition 42 may simply include an indicator of accessing the IMS8 through the third access network 63. Moreover, the IRS-2 72 alsoincludes a registration status 52 to indicate the registration statusapplicable for all the IMPUs in said IRS-2. In particular, as shown inFIG. 4, both IMPU-12 a and IMPU-6 2 f share the unique SP, namely SP-A 6a, as for the IRS-1; whereas both IMPU-2 2 b and IMPU-3 2 c share aunique SP, namely SP-C 6 c. As already commented above, IMPU-1 andIMPU-6 sharing a unique SP and being included in the same IRS are saidto be alias IMPUs, as IMPU-2 and IMPU-3 respectively do as well.

To this end, the HSS 81 may comprise a storage 13 for storing the datastructure per subscriber; a receiver 12 for receiving the explicitregistration of the given IMPU-12 a under the given access condition 42;and a processor 10 for triggering the implicit registration of IMPUs 2a, 2 b, 2 c, 2 f in the IRS-2 72 associated with said access condition42. In an embodiment of the invention, the HSS 81 may further comprise asender 11 for submitting those IMPUs 2 a, 2 b, 2 c, 2 f in the IRS-2 72associated with said access condition 42 as a result of the explicitregistration of the given IMPU-12 a. In particular, the storage 13 maycomprise a memory handler 130 for submitting and retrieving data from anexternal database 131, where the database is provided by a third partysupplier, or may comprise an internal database, not shown in anydrawing, cooperating with other functional entities of the HSS 81.

Also to this end, the S-CSCF 82 may include a receiver 22 for receivingan explicit registration of the given IMPU-12 a, and a sender 21 forsubmitting the explicit registration of said IMPU towards HSS 81,wherein this sender 21 may be also arranged for submitting towards theHSS the given access condition for which the explicit registrationapplies.

In operation, and where a given IMPU is shared by more than one IRS, theexplicit registration of said given IMPU under a given access conditiontriggers the implicit registration of those IMPUs in the IRS associatedwith said access condition, whilst the registration status of IMPUs inany other IRS, which is associated with a different access condition,remain unchanged. Once the exemplary data structure of FIG. 4 has beendefined for a given user 91 in a FMC network as shown in FIG. 3,different sequences of actions can be followed by the user in respect ofregistrations of IMPI/IMPU pairs in the IMS 8.

FIG. 7 illustrates an exemplary sequence of actions that the user 91 maycarry out at in the course of accessing the IMS 8. The user may make useof the mobile terminal 9 a to register IMPU-12 a, Bob@ims.com, with aSIP Register message in step S-200. Such message reaches the IMS via thethird access network 63, and is transmitted through the IMS Core networkuntil reaching a S-CSCF 82 assigned for serving the user. The S-CSCF 82receiving such message submits during a step S-205 a correspondingexplicit registration towards the HSS 81 in charge of the user, likelywith a SAR message, providing the IMPU-1 to be registered along with anindication to determine the access condition to be applied.

The HSS 81 receiving such explicit registration of IMPU-1 determinesthat the IRS-2 72 includes the received IMPU-12 a and matches the accesscondition 42, and triggers the implicit registration of those IMPUs insaid IRS-2 72. Then, the HSS submits during a step S-210 to the S-CSCF82 currently serving the user, likely with a SAA message, those IMPUs insaid IRS-2 72 (namely IMPU-1, IMPU-6, IMPU-2 and IMPU-3), likelyaccompanied by respectively associated SP-A 6 a and SP-C 6 c and othersubscriber data. The submission of SPs and other subscriber data is notsignificant for the purpose of the invention. Eventually, the user 91 isinformed through the mobile terminal 9 a, during a step S-215, of theimplicit registration of IMPU-1, IMPU-6, IMPU-2 and IMPU-3, likely witha SIP 200 OK message.

The exemplary sequence of actions illustrated in FIG. 7 continues wherethe user makes use of the desktop PC 9 d connected to a fixed line toaccess the IMS 8. The user 91 carries out during a step S-220 a newexplicit registration of IMPU-12 a, Bob@ims.com, from the desktop PC 9 dwith a SIP Register message. The message reaches the IMS via the firstaccess network 61, and is transmitted through the IMS Core network untilreaching the S-CSCF 82 assigned for serving the user. As for theprevious registration, the S-CSCF 82 receiving such message submitsduring a step S-225 a corresponding explicit registration towards theHSS 81 in charge of the user, likely with a SAR message, providing theIMPU-1 to be registered along with an indication to determine the accesscondition to be applied.

In this particular case, the access condition to match is the accessthrough the first access network 61, and the IRS-1 71 in the HSS 81 hadbeen configured with an access condition 41 built up as the result ofperforming the logic operation: ‘access through the first access network61’ OR ‘access through the second access network 62’.

The HSS 81 receiving such new explicit registration of IMPU-1 determinesthat the IRS-1 71 also includes the received IMPU-12 a and matches theaccess condition 41, and triggers the implicit registration of thoseIMPUs in said IRS-1 71. Then, the HSS submits during a step S-230 to theS-CSCF 82 currently serving the user, likely with a SAA message, thoseIMPUs in said IRS-1 71 (namely IMPU-1, IMPU-6, IMPU-4 and IMPU-5),likely accompanied by respectively associated SP-A 6 a and SP-B 6 b andother subscriber data. As before, the submission of SPs and othersubscriber data is not significant for the purpose of the invention.Eventually, the user 91 is informed through the desktop PC 9 d, during astep S-235, of the implicit registration of IMPU-1, IMPU-6, IMPU-4 andIMPU-5, likely with a SIP 200 OK message.

At the present situation, and following the two implicit registrationsof IRS-1 71 and IRS-2 72 carried out at the HSS 81 as a result of thetwo explicit registrations of the IMPU-12 a under different accessconditions 41 and 42, the HSS 81 has recorded said two implicitregistrations of IRS-1 71 and IRS-2 72 in order to preclude any furtherpartial deregistration of corresponding IMPUs.

To this end, the processor 10 of the HSS 81 may be arranged forrecording in the storage 13 the implicit registration of IMPUs in anyIRS in order to preclude partial deregistration of IMPUs in said IRS. Inparticular, the implicit registration of IMPUs in the IRS associatedwith said access condition.

Before explaining how the user 91 may deregister any currentlyregistered IMPU, some exemplary embodiments of communications betweenthe user 91 and any other user may be presented.

For example, FIG. 8 illustrates an exemplary embodiment where anotheruser 92 initiates a number of calls, or communications, towards thegiven user 91. Said another user 92 may initiate a communication toreach the given user 91 at home and, particularly, to the wirelineterminal 9 b since calls to fixed line terminals are usually cheaperthan the charging applicable to mobile terminals 9 a. To this end, theanother user 92 dials +9876543210, namely the IMPU-5, and the call issignalled during a step S-250 towards the S-CSCF 82 currently servingthe given user 91. The S-CSCF 82 processes such call signalling and,finding the indicated IMPU-5 amongst those already registered in theHSS, submits during a step S-255 an invitation to communicate towardsthe wireline terminal 9 b identified by the indicated IMPU-5, likelywith a SIP Invite message. Simultaneously with this call, or afterwards,the same another user 92 or any other user may want to initiate acommunication towards the desktop PC 9 d at home of the given user 91.To this end, the another user 92 types the destination addressBob@wireline, namely the IMPU-4, and the call is signalled during a stepS-260 towards the S-CSCF 82 currently serving the given user 91. TheS-CSCF 82 processes such call signalling and, finding the indicatedIMPU-4 amongst those already registered in the HSS, submits during astep S-265 an invitation to communicate towards the desktop PC 9 didentified by the indicated IMPU-4, likely with a SIP Invite message.

On the other hand, the same another user 92 or any other user may wantto also initiate a communication towards a laptop PC connected to themobile terminal 9 a of the given user 91. To this end, the another user92 types the destination address Bob@wireless, namely the IMPU-2, andthe call is signalled during a step S-270 towards the S-CSCF 82currently serving the given user 91. The S-CSCF 82 processes such callsignalling and, finding the indicated IMPU-2 amongst those alreadyregistered in the HSS, submits during a step S-275 an invitation tocommunicate towards the laptop PC through the mobile terminal 9 aidentified by the indicated IMPU-2, likely also with a SIP Invitemessage. Likewise, the same another user 92, or any other user, may wantto initiate a phone call towards the mobile terminal 9 a of the givenuser 91. To this end, the another user 92 dials +1234567890, namely theIMPU-3, and the call is signalled during a step S-280 towards the S-CSCF82 currently serving the given user 91. The S-CSCF 82 processes suchcall signalling and, finding the indicated IMPU-3 amongst those alreadyregistered in the HSS, submits during a step S-285 an invitation tocommunicate towards the mobile terminal 9 a identified by the indicatedIMPU-3, likely with a SIP Invite message.

Regarding an unregistered state and deregistered state that any IMPU mayhave, FIG. 10 illustrates an exemplary embodiment of the flow of actionsthat may be initiated in accordance with the invention to deregister anIMPU through the mobile terminal 9 a, as well as to deregister an IMPUthrough the desktop PC 9 d. As already commented above, just those IMPUsof the SIP URI type can be used during registration procedures, being tomake an IMPU get the registered state, unregistered state orderegistered state.

FIG. 10 thus starts with a signalling message submitted from the mobileterminal 9 a during a step S-300 instructing the IMS 8 to deregister theIMPU-6 2 f, namely Bob@bobdomain. Such message is received at the S-CSCF82 currently serving the user 91, which forwards a corresponding oneduring a step S-305 towards the HSS 81, likely with a SAR messageindicating said IMPU-6 along with an indication to determine the accesscondition to be applied, that is, accessing the IMS through the thirdaccess network 63. The HSS 81, upon receiving such instruction toderegister the IMPU-6, determines that the IRS-2 72 includes thereceived IMPU-6 2 f and matches the access condition 42, and triggersthose IMPUs in said IRS-2 72 being implicitly deregistered. Then, theHSS 81 submits during a step S-310 to the S-CSCF 82 currently servingthe user, likely with a SAA message, those IMPUs in said IRS-2 72(namely IMPU-1, IMPU-6, IMPU-2 and IMPU-3) that have been deregistered.Eventually, the mobile terminal 9 a is informed during a step S-315 thatIMPU-1, IMPU-6, IMPU-2 and IMPU-3 have been deregistered. Even thoughnot illustrated in any drawing, a similar mechanism may also be appliedbetween the S-CSCF 82 and the HSS 81 to make an IMPU being explicitlyunregistered and, subsequently, those IMPUs in the corresponding IRS forthe associated access condition being thus implicitly unregistered.

FIG. 10 continues with a signalling message submitted from the desktopPC 9 d during a step S-320 instructing the IMS 8 to deregister theIMPU-4 2 d, namely Bob@wireline. Such message is received at the S-CSCF82 currently serving the user 91, which forwards a corresponding oneduring a step S-325 towards the HSS 81, likely with a SAR messageindicating said IMPU-4 along with an indication to determine the accesscondition to be applied, that is, accessing the IMS through the firstaccess network 61. The HSS 81, upon receiving such instruction toderegister the IMPU-4 2 d, determines that the IRS-1 71 includes thereceived IMPU-4 2 d and matches the access condition 41, and triggersthose IMPUs in said IRS-1 71 being implicitly deregistered. Then, theHSS 81 submits during a step S-330 to the S-CSCF 82 currently servingthe user, likely with a SAA message, those IMPUs in said IRS-1 71(namely IMPU-1, IMPU-6, IMPU-4 and IMPU-5) that have been deregistered.Eventually, the desktop PC 9 d is informed during a step S-335 thatIMPU-1, IMPU-6, IMPU-4 and IMPU-5 have been deregistered. Even thoughnot illustrated in any drawing, a similar mechanism may also be appliedbetween the S-CSCF 82 and the HSS 81 to make an IMPU being explicitlyunregistered and, subsequently, those IMPUs in the corresponding IRS forthe associated access condition being thus implicitly unregistered.

In the above exemplary embodiments, the registration status 51 52 ofeach IRS adopts a unique value ‘registered’, ‘unregistered’ or‘deregistered’ applicable to those IMPUs in each IRS 71 72.

To this end, the receiver 12 of the HSS 81 may be arranged for receivinga deregistration of an IMPU in an IRS, or instruction to make the IMPUunregistered, which implicit registration was recorded in the storage13, and the processor 10 may be arranged for triggering thederegistration of those IMPUs in said IRS, or to make those IMPUsunregistered. Moreover, the receiver 12 may further be arranged forreceiving a given access condition along with a deregistration of anIMPU, or the instruction to make it unregistered, and the processor 10may further be arranged for using the given access condition todetermine a deregistration of those IMPUs in an IRS associated with saidaccess condition, or to make them unregistered, as the case might be.

Also to this end, the sender 21 of the S-CSCF 82 may further be arrangedfor submitting towards the HSS 81, along with a deregistration of anIMPU, a given access condition for which the deregistration applies.

The data structure explained above, whereby a given IMPU can be sharedby more than one IRS, each IRS being associated with an accesscondition, and the explicit registration of the given IMPU, under agiven access condition, triggering the implicit registration of thoseIMPUs in the IRS associated with the given access condition, may wellfulfil the above regulatory requirements in the field of EmergencyCalls.

In this respect, the exemplary data structure illustrated in FIG. 5includes a third IRS 73, namely IRS-3, to be implicitly registered wherethe user accesses the IMS 8 for an emergency call through the homeenvironment shown in FIG. 3, that is, through a first access network 61or through a second access network 62; and a fourth IRS 74, namelyIRS-4, to be implicitly registered where the user accesses the IMS 8 foran emergency call through the mobile environment shown in FIG. 3, thatis, through a third access network 63. For the sake of simplicity inrespect of the present invention, all IMPUs in both IRS-3 and IRS-4 arealso associated with the same couple of IMPIs of the given user 91 asbefore, namely IMPI-13 a and IMPI-2 3 b.

Where the regulatory requirements impose a dedicated IMPU to beregistered for Emergency Calls, a so-called Emergency IMPU (hereinafterE-IMPU), such E-IMPU may be shared, in accordance with the presentinvention, by every IRS wherein the emergency is included as, at leastpart of, the access condition.

This third IRS 73 of the data structure, namely IRS-3 usable foremergency calls from the home environment, includes the E-IMPU 2 gusable for registration of an emergency call, and may also include theIMPU-12 a, namely Bob@ims.com, identifying the user in the IMS 8, andthose IMPUs of the user 91 in the home environment: the IMPU-4 2 d,namely Bob@wireline, and the IMPU-5 2 e, namely +9876543210. Inaddition, this IRS-3 may also include IMPU-6 2 f, namely Bob@bobdomain,as alias IMPU of IMPU-1. This IRS-3 73 also includes, in accordance withthe invention, an access condition 43 to be matched in order to carryout the implicit registration of IMPUs in the emergency IRS-3.

In this case, the access condition 43 is built up as the result ofperforming the logic operation: ‘emergency call’ AND [‘access throughthe first access network 61’ OR ‘access through the second accessnetwork 62’].

As for the previous IRS-1, the emergency IRS-3 also includes aregistration status 53 to indicate the registration status applicablefor all the IMPUs in said IRS-3. In particular, as shown in FIG. 5, bothIMPU-12 a and IMPU-6 2 f share a unique SP, namely SP-A 6 a; whereasboth IMPU-4 2 d and IMPU-5 2 e share a unique SP, namely SP-B 6 b. TheE-IMPU may be simply associated with a sort of default profile 6 d,namely SP-null, since no particular service capabilities are used foremergency calls, other than being used to trigger the implicitregistration of IMPUs in the emergency IRS-3 or IRS-4, and especiallythose of the TEL URI type usable for call-back purposes.

The FIG. 5 also illustrates the fourth IRS 74 of the data structure,namely IRS-4 usable for emergency calls from the mobile environment.This IRS-4 74 also includes the E-IMPU 2 g usable for registration of anemergency call, and may also include the IMPU-12 a, namely Bob@ims.com,identifying the user in the IMS 8, and those IMPUs of the user 91 in themobile environment: the IMPU-2 2 b, namely Bob@wireless, and the IMPU-32 c, namely +1234567890. In addition, this IRS-4 may also include IMPU-62 f, namely Bob@bobdomain, as alias IMPU of IMPU-1. This IRS-4 74 alsoincludes, in accordance with the invention, an access condition 44 to bematched in order to carry out the implicit registration of IMPUs in theemergency IRS-4.

In this case, the access condition 44 is built up as the result ofperforming the logic operation: ‘emergency call’ AND ‘access through thethird access network 63’.

As for the previous IRS-2, the emergency IRS-4 also includes aregistration status 54 to indicate the registration status applicablefor all the IMPUs in said IRS-4. In particular, as shown in FIG. 5, bothIMPU-12 a and IMPU-6 2 f share a unique SP, namely SP-A 6 a; whereasboth IMPU-2 2 b and IMPU-3 2 c share a unique SP, namely SP-C 6 c. TheE-IMPU may be simply associated, as in IRS-3, with a sort of defaultprofile 6 d, namely SP-null, since no particular service capabilitiesare used for emergency calls other than allowing the implicitregistration of IMPUs of the TEL URI type usable for call-back purposes.

In operation, FIG. 6 illustrates an exemplary embodiment of the user 91making an emergency call through the mobile terminal 9 a via the IMS 8.The sequence of actions starts with an explicit registration of theE-IMPU carried out during a step S-100 through the mobile terminal 9 a.Such message reaches the IMS via the third access network 63, and istransmitted through the IMS Core network until reaching a S-CSCF 82assigned for serving the user. The S-CSCF 82 receiving such messagesubmits during a step S-105 a corresponding explicit registrationtowards the HSS 81 in charge of the user, likely with a SAR message,providing the E-IMPU 2 g to be registered along with an indication todetermine the access condition to be applied.

The HSS 81 receiving such explicit registration of the E-IMPU determinesthat the IRS-4 74 includes the received E-IMPU 2 g and matches theaccess condition 44, and triggers the implicit registration of thoseIMPUs in said IRS-4 74. Then, the HSS submits during a step S-110 to theS-CSCF 82 currently serving the user, likely with a SAA message, thoseIMPUs in said IRS-4 74 (namely IMPU-1, IMPU-6, IMPU-2 and IMPU-3), or atleast those of the TEL URI type (IMPU-3: +1234567890), likelyaccompanied by respectively associated SP-A 6 a and SP-C 6 c and othersubscriber data. As already commented above, the submission of SPs andother subscriber data is not significant for the purpose of theinvention. Eventually, the user 91 is informed through the mobileterminal 9 a, during a step S-115, of the implicit registration ofIMPU-1, IMPU-6, IMPU-2 and IMPU-3, likely with a SIP 200 OK message orthe like.

The exemplary sequence of actions illustrated in FIG. 7 continues wherethe user makes the emergency call towards an Emergency Call SessionControl Function 83 (hereinafter E-CSCF) during a step S-120. Suchemergency call always includes a TEL URI identifying a user terminal, oruser equipment, where the user is reachable: in this case, the IMPU-3.Then, the E-CSCF forwards such emergency call towards the ERC 93 duringa step S-125. Whenever the ERC 93 needs to communicate with the user 91,for example during a step S-130, it initiates a call back making use ofthe received TEL URI addressing the user, namely IMPU-3. Such call backis signalled towards the S-CSCF 82 serving the user, as for anyconventional incoming call, and the S-CSCF forwards such call backsignalling towards the mobile terminal 9 a currently in use by the user91.

Regarding implementation of embodiments, the invention can be practisedby a computer program, which is loadable into an internal memory of acomputer that includes input and output units as well as a processingunit. This computer program comprises executable code portions adaptedto carry out sequences of actions described under the above embodimentswhen running in the computer. In particular, the computer program may berecorded in a carrier computer-readable medium, such as a CD-ROM.

The invention is described above in respect of several embodiments in anillustrative and non-restrictive manner. Obviously, variations, andcombinations of these embodiments are possible in light of the aboveteachings, and any modification of the embodiments that fall within thescope of the claims is intended to be included therein.

The invention claimed is:
 1. A Home Subscriber Server (HSS) holdingsubscriber data of users of an Internet protocol Multimedia Subsystem(IMS), the HSS having a data structure stored on a non-transitorycomputer readable medium per subscriber that includes a plurality of IMSPublic User Identities, each IMS Public User Identity (IMPU) associatedwith at least one IMS Private User Identity (IMPI), wherein a number nof IMPUs is distributed in a number m of Implicit Registration Sets, andwherein all the IMPUs in each Implicit Registration Set (IRS) share asame registration status, wherein each IRS is associated with an accesscondition, a given IMPU is shared by more than one IRS, and an explicitregistration of the given IMPU under a given access condition triggersan implicit registration of the IMPUs in the IRS associated with thegiven access condition, wherein a registration status of IMPUs in anyother IRS remain unchanged.
 2. The HSS of claim 1, wherein an explicitregistration of an IMPU, which belongs only to one IRS, triggers animplicit registration of the IMPUs in the IRS for an associated accesscondition.
 3. The HSS of claim 1, wherein the given access condition isselected from a group of access conditions that includes a mobile accessonly, a fixed access only, emergency call, roaming network, andcombinations thereof.
 4. The HSS of claim 1, wherein the implicitregistration of IMPUs in the IRS associated with the given accesscondition is recorded in order to preclude partial deregistration of theIMPUs in the IRS.
 5. The HSS of claim 2, wherein the implicitregistration of IMPUs in the IRS is recorded in order to precludepartial deregistration of the IMPUs in the IRS.
 6. The HSS of claim 4,wherein a deregistration of an IMPU in the IRS, which implicitregistration was recorded, triggers the deregistration of the IMPUs inthe IRS.
 7. The HSS of claim 1, further comprising a receiver forreceiving the explicit registration of the given IMPU under the givenaccess condition and a processor for triggering the implicitregistration of IMPUs in the IRS associated with the given accesscondition.
 8. The HSS of claim 7, further comprising a sender forsubmitting the IMPUs in the IRS associated with the given accesscondition as a result of the explicit registration of the given IMPU. 9.The HSS of claim 7, wherein the processor is arranged for recording theimplicit registration of IMPUs in the IRS associated with the givenaccess condition in order to preclude partial deregistration of IMPUs inthe IRS.
 10. The HSS of claim 7, wherein the processor is arranged forrecording the implicit registration of IMPUs in the IRS in order topreclude partial deregistration of IMPUs in the IRS.
 11. The HSS ofclaim 9, wherein the receiver is arranged for receiving a deregistrationof an IMPU in an IRS, and the processor is arranged for triggering thederegistration of the IMPUs in the IRS.
 12. The HSS of claim 7, whereinthe receiver is further arranged for receiving a given access conditionalong with a deregistration of an IMPU, and the processor is furtherarranged for using the given access condition to determine aderegistration of the IMPUs in an IRS associated with the given accesscondition.
 13. The HSS of claim 7, further comprising a memory handlerfor submitting and retrieving data from an external database.
 14. Amethod of carrying out an implicit registration of one ImplicitRegistration Set (IRS) amongst a plurality of IRSs operable on aprocessor of a Home Subscriber Server (HSS), each IRS comprising morethan one Internet protocol Multimedia Subsystem (IMS) Public UserIdentity (IMPU) and the IMPUs in each IRS sharing a same registrationstatus, the method comprising: distributing a number n of IMPUs in anumber m of IRSs; sharing a given IMPU by more than one IRS; associatingeach IRS with an access condition; carrying out an explicit registrationof the given IMPU under a given access condition; and triggering animplicit registration in the HSS of the IMPUs in an IRS associated withthe given access condition, whilst a registration status of IMPUs in anyother IRS remain unchanged.
 15. The method of claim 14, furthercomprising carrying out an explicit registration of a second IMPU, whichbelongs only to one IRS, and responsive to the carrying out the explicitregistration of the second IMPU, triggering an implicit registration ofIMPUs in the IRS for an associated access condition.
 16. The method ofclaim 14, wherein the given access condition is selected from a group ofaccess conditions that includes a mobile access only, a fixed accessonly, emergency call, roaming network, and combinations thereof.
 17. Themethod of claim 14, further comprising recording the implicitregistration of IMPUs in the IRS associated with the given accesscondition in order to preclude partial deregistration of the IMPUs inthe IRS.
 18. The method of claim 15, further comprising recording theimplicit registration of IMPUs in the IRS in order to preclude partialderegistration of the IMPUs in the IRS.
 19. The method of claim 17,further comprising deregistering the IMPUs in an IRS, which implicitregistration was recorded, upon a deregistration of an IMPU in the IRS.20. The method of claim 14, further comprising receiving a given accesscondition along with a deregistration of an IMPU, and using the givenaccess condition to determine a deregistration of the IMPUs in an IRSassociated with the given access condition.
 21. A Serving Call SessionControl Function (S-CSCF) server serving subscribers of an Internetprotocol (IP) Multimedia Subsystem (IMS), the S-CSCF server having areceiver for receiving an explicit registration of an IMS Public UserIdentity (IMPU) of a given subscriber, the IMPU being shared by morethan one Implicit Registration Set (IRS), each IRS being associated withan access condition, and a sender for submitting the explicitregistration of the IMPU towards a Home Subscriber Server (HSS) holdingsubscriber data for users of the IMS, wherein the sender is arranged forsubmitting a given access condition for which the explicit registrationapplies.
 22. The S-CSCF server of claim 21, wherein the given accesscondition is selected from a group of access conditions that includes amobile access only, a fixed access only, emergency call, roamingnetwork, and combinations thereof.
 23. The S-CSCF server of claim 21,wherein the sender is further arranged for submitting towards the HSS,along with a deregistration of an IMPU, a given access condition forwhich the deregistration applies.